1.1. Field of the Invention
The present invention refers to the field of networked computer telecommunication, and in particular to a method and system for processing contract data defining contracts between a service requester and a service provider for services like Web Services to be provided via a network.
1.2. Description and Disadvantages of Prior Art
1.2.1. Introduction
Web services define a technique for describing software components to be accessed, methods for accessing these components, and discovery methods that enable the identification of relevant service providers. Web services are programming language-, programming model-, and system software neutral.
In this regard, two prior art Web services standards are relevant. They are shortly sketched out and commented as follows in order to introduce into the problems concerned in prior art:
First, the Simple Object Access Protocol (SOAP) provides a means of messaging between a service provider and a service requester. SOAP is independent of the underlying transport protocol, SOAP payloads can be carried on HTTP, FTP, JMS and other protocols.
FIG. 1 gives a SOAP example carried by the HTTP POST request.
HTTP messages consist of requests from client to server and responses from server to client. Both types of message (Request and Response messages) consist of a start-line, zero or more header fields (also known as “headers”), an empty line indicating the end of the header fields, and possibly a message-body.
The structure of a HTTP request message is depicted in FIG. 2: the first line of that message specifies the method to be applied to the resource, the identifier of the resource, and the HTTP protocol version in use. The HTTP protocol defines multiple request methods like GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, OPTIONS. The method indicates the operation to be performed on the resource.
The resource upon which to apply the request is identified by a Request-URI, which is a Uniform Resource Identifier. Uniform Resource Identifiers are simply formatted strings, which identify—via name, location, address or any other characteristic—a resource. For example: The well-known HTTP URL scheme used to locate network resources via the HTTP protocol contains resource-URIs. The scheme specific syntax and semantics for http URLs are http_URL=“http:”“//”host [“:”port][request-uri]
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI identifies the resource. The syntax and semantics for Request-URI are Request-uri=abs_path [“?” query-string]
where the abs_path is an identifier of the resource and the query string is any kind of information which can be used for processing the request.
The header fields carry meta-information associated with the request or response.
The message-body of an HTTP message is used to carry the entity-body associated with the request or response.
The message body depicted in FIG. 2 contains the actual SOAP message, which has a structure as given in FIG. 3: Inside an envelope section a number of header fields 1, . . . n are defined, which construct the so called SOAP header, which is followed by the actual SOAP body, which comprises a second number of so called “Body fields 1, . . . n.
Thus, the overall structure of a SOAP message carried over a network e.g. by a transport protocol like HTTP is depicted as a conglomeration of FIGS. 1 to 3 in FIG. 4.
FIG. 1 gives a SOAP example carried by the HTTP POST command. The HTTP request method is POST, the resource-URI is “/StockQuote”, which is an absolute path identifying the resource for which the request is intended. The resource-URI does not contain a query string.
Beside SOAP, there is in prior art the above-mentioned second relevant Web Service standard:
The Web Services Description Language (WSDL) is an XML document for describing Web Services as a set of endpoint operations on messages containing either document-oriented or Remote Procedure Call (RPC) payloads.
So called service interfaces are defined abstractly in terms of message structures and sequences of simple message exchanges (or “operations” in WSDL terminology). They are then bound to a concrete network protocol and data-encoding format to define an endpoint. Related concrete endpoints are bundled to define abstract endpoints (services).
WSDL supports a service interface definition that is distinct from the protocol bindings used for service invocation. WSDL allows for multiple bindings for a single service. The service interface definition and the access binding are also distinct from the implementation of the functionality of the service. Service requesters usually generate client stub code for a web service from the corresponding WSDL; the WSDL of a service is usually requested from the service provider. The client stub code implements the necessary logic to create the correct message structure and the correct data encoding to address the endpoint. Since there is a distinction between definition, binding and implementation of a service, client stub codes created for a certain definition and binding can usually address various endpoints without requiring code changes, simply by using another endpoint address. FIG. 5A and the continuation thereof, FIG. 5B is given to disclose an exemplary WSDL document with further details to a person skilled in the art.
An important feature of Web Services is that they are stateless, according to a request-response scheme. A stateless server is one, which treats each request as an independent transaction, unrelated to any previous request. This simplifies the server design because it does not need to allocate storage to deal with conversations in progress or worry about freeing it if a client dies in mid-transaction. A disadvantage is that it may be necessary to include more information in each request and this extra-information will need to be interpreted by the server each time.
Having now described the constraints in which electronic communication of the above-mentioned kind runs, the disadvantages of prior art will be described next below:
Commercial usage of web services is based on a contract concluded between the service provider and the service requester. Such contract represents an agreement about the conditions for using and provisioning web services or web applications. The contract details may specify the conditions for billing the service, i.e. the price, service levels specifying the desired quality of service in a more detailed way, and further information which is highly critical for both the service requester and the service provider. Basically, in prior art business, there are no limitations regarding the scope of a contract or the number of contracts: one contract may contain multiple services, or one service may be contained in multiple contracts, which are all valid at the same time.
In a typical prior art scenario, either two parties, ie, the Service Requester or Service Consumer, referred to herein as SC, and the Service Provider, referred to as SP, communicate, or three parties are comprised of the Web service Communication, ie the Service Requester, the Service provider who manages the above contracts and the Service Supplier, referred to as SS, which actually performs the service, which is sometimes hold invisible to the requester.
The only disclosure of such prior art, which is thus elaborated to address the above-mentioned web services facilities is published in “IBM Web Services Toolkit”, “Emerging Technologies Toolkit”, available in the year of 2002 for a trial period of 60 days under www.alphaworks.com.
A short review on a software component as it is disclosed there, which is called “Contract Service” and comprises the most technical features relevant for the present invention is given, as follows:
The Contract Service handles the relationship between service providers and service requestors. It provides information about the type of contract between a service provider and the service hub (deployment contracts, also known as provider contracts) and between a service requestor and the service hub (usage contracts). Usage contracts can be used to subscribe to any combination of operations of any service provided through the service hub. A usage contract contains information such as how calls to service operations are to be charged for (by time, by number of uses, by amount of use etc.) and how much the subscribed service operations should cost for that client. For each usage contract the Contract Service defines the payment method and rating model to be used, the effective dates for that contract. Contracts may optionally store the digital signatures of both parties (service hub and service provider/requestor) to the contract. In the Utility Service demo that is shipped with the Web Services Toolkit, contracts are added to the Contract Service via a Utility Services Portal supplied with the demo, and a valid contract must be in place between a service hub and a service requestor before the requestor can use the service.
The Contract Service supports WSDL-defined operations such as the following:                createContract for creating a contract;        getContractModel for reading a contract model;        getContractState for reading the current status of a contract;        updateConstractState for updating the current status of a contract;        getContractType for reading the type of a contract;        setContractProperty for setting the properties of a contract;        getContractProperty for reading the properties of a contract;        getUsageContractsForValidForIdentity for retrieving usage contracts, which are valid for a given Service consumer        
When now a service request arrives at the server, the contracting service described above checks the contracts being relevant for the service request prior to execution of the request. As long as only one contract exists and the underlying service can be performed in a single way without the possibility to differentiate into multiple levels of quality of service, the service can be provided without any further problem.
Due to the steadily increasing offering and use of web services, however, those web services split up into a large variety of quality levels, in which they may be provided by a respective service provider. For example, a service may be provisioned very quickly which makes the service more expensive compared to a longer “service provision time”. Or, the information given by the service may be more or less elaborate and thus may give more or less details to the service requester, for example the respectively varying contents of an economic information system. Thus, a respective multiple number of contracts or contract attributes are valid and binding between service provider and service requester. In this situation, say, if multiple contracts or contract attributes are relevant and valid, the above-mentioned contracting service has to select the actual contract to be used for the request or to use the actual contract attribute in case one single contract specifies a respective number of contract attributes for different quality levels of a service. The selected contract or contract attribute specifies then the current conditions for the current service request, e.g. the price of the operation, as mentioned above.
As the requests sent over the network do not contain any kind of contract specification or contract related information, a client at the service requester side in prior art cannot select the actual contract to use for a specific service request in such multiple contract situation, nor the client can influence the process of selection. In other words: the precise conditions, under which a request is provisioned and is in effect for the requester, are selected in prior art by a foreign party, i.e. by the service provider. This disadvantage is based in particular upon the fact that the existing web service protocol standards, as UDDI, WSIL, WSDL, SOAP, do not consider any methods for selecting contracts for an operation or service request.
The unsatisfying handling of this problem means that either the service provider selects the actual contract or actual contract attribute, while the requester has no influence on said selection, or a complicated service structure is used, which is organised such that for each granular quality level for the same service a separate contract is defined and thus one and the same service splits up logically and formally into a respective number of services. This however, renders the man-machine-interface for a Service Consumer complicated and difficult to use.
1.3. Objectives of the Invention
It is thus an objective of the present invention to provide improvements to the method according to the preamble of claim 1, and a respective system for performing the method, wherein the above mentioned disadvantages are avoided or at least reduced.